1. Technical Field
This invention relates to processing control messages for use in communications network, and in particular to a method, data processing system and software application program for processing control messages constructed in accordance with communications control protocol. The invention is particularly, but not exclusively, direct to text-based application-layer communication control protocol.
2. Related Art
The Session Initiation Protocol (SIP) is an application-layer control protocol for creating, modifying and terminating sessions having one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these. SIP supports session descriptions that allow participants to agree on a set of compatible media types. It also supports user mobility by proxying and redirecting requests to the user's current location. SIP is not tied to any particular conference control protocol. There is widespread interest in the protocol, especially for telephony-related applications. SIP was proposed by the Internet Engineering Task Force (IETF) group and is now a proposed standard published as RFC 2543.
The entities used in SIP are user agents, proxy servers, redirect servers and location servers. A SIP user agent is an end-system that allows a user to participate in a session. A SIP user agent contains both a user agent client and a user agent server. A user agent client is used to initiate a session and a user agent server is used to respond to request from a user agent client. A user is addressed using an email-like address identifier “user@host”, where “user” is a user name or phone number and “host” is a domain name or numerical Internet Protocol (IP) address. SIP defines a number of request types, in particular INVITE, ACK, BYE, OPTIONS, CANCEL, and REGISTER. Responses to SIP messages indicate success or failure, distinguished by status codes, 1xx (100 to 199) for progress updates, 2xx for success 3xx for redirection, and higher numbers for failure. Each new SIP transaction has a unique call identifier (call ID), which identifies the session. If the session needs to be modified, e.g., for adding another media, the same call identifier is used in the initial request, in order to indicate that this is a modification of an existing session.
The SIP user agent has two basic functions: listening for incoming SIP messages, and sending SIP messages upon user actions or incoming messages. The SIP user agent typically also starts appropriate applications according to the session that has been established. The SIP proxy server relays SIP messages, so that it is possible to use a domain name to find a user, for example using the Domain Name System (DNS) rather than knowing the IP address or name of the host. A SIP proxy can thereby also be used to hide the location of the user. A redirect server returns the location of the host rather than relaying the SIP message. Both redirect and proxy servers accept registrations from users, in which the current location of the user is given. The user's location can be stored at a dedicated location server.
SIP is typically implemented by transmitting Internet Protocol (IP) packets. SIP is independent of the packet layer and only requires an unreliable datagram service, as it provides its own reliability mechanism. While SIP typically is used over UDP or TCP, it could be used over frame relay, ATM AAL5 or X.25.
SIP is a text based protocol and is based to a certain extent (in terms of syntax) on the HTTP protocol. A typical message consists of a single request line, a number of header lines and a message body.
The request line indicates the type of the messages, the message destination and the SIP version it complies with. The following is a typical example:
INVITE sip:Richard@bt.com SIP/2.0
A header line contains the name of the header type, followed by a semicolon and the contents as these are defined for the specific header. Consequently, each header type is used for a specific purpose (either to indicate some parameters or to issue a request). The following are typical examples:
From: sip:Richard@bt.com
To: sip:Steve@bt.com
Subject: Official meeting
The message body may be of any content, although it usually has contents formatted in accordance with the Session Description Protocol (SDP).
SIP URL address identifiers such as sip:Richard@bt.com are required for the exchange of SIP messages in a similar way that e-mail URL address identifiers are required for the exchange of electronic mail.
By using an e-mail type address it is possible to deliver a SIP message to a SIP server that knows the location of the user or user agent server the message is intended for. The IP address of the SIP server having authority for the callee's address can be readily determined by DNS. However, this approach requires users of both SIP and e-mail services to be allocated different and potentially confusing SIP and e-mail addresses. This exacerbates the problem of address memory, address book maintenance and in particular, address resolution using database queries. A further problem associated with SIP is that as a newly implemented protocol there is no delivery guarantee, that is to say delivery of a SIP message addressed using a SIP URL may fail, for instance because the intended recipient is not enabled to receive SIP messages.